The failure that's happening with Ubuntu + Boost 1.70 might be expected: boostorg/thread#297. I think you'll see that with any version of Boost between 1.69 and 1.72.

Some of the macOS errors are caused by an incompatibility with Clang that was fixed in Boost 1.81: boostorg/numeric_conversion@50a1eae

Anecdotally, I can say that I also haven't had any issues with these changes on Windows 11 with Boost 1.89.

The only problem I've had, which is an existing issue in the master branch, is that the async functions added in #195 don't compile when using some newer Asio completion token types. For example, azmq::async_send(socket, buffers, asio::deferred) will give a compilation error due to the usage of BOOST_ASIO_INITFN_RESULT_TYPE in the function signature.

It looks like Asio's async operations now use the return type of async_initiate directly instead of the result macro. For example, the signature of azmq::async_send might be

template<class CompletionToken, class ConstBufferSequence>
auto async_send(azmq::socket &socket, ConstBufferSequence const &buffers, CompletionToken &&token)
-> decltype(
      boost::asio::async_initiate<CompletionToken, void(boost::system::error_code, size_t)>(
          std::declval<async_send_initiation<ConstBufferSequence>>(), token))

I don't know if this necessarily needs to be fixed in this PR, but it's worth noting.

The branch was getting too polluted with my attempts at making it work for all versions so I cleaned it up a little.

The failure that's happening with Ubuntu + Boost 1.70 might be expected: boostorg/thread#297.

I've given up on getting it to work for 1.70 because of the issues commented by @cbrl. The point of the PR is not to fix Boost, so I guess that's something we can live with.

One of the breaking changes is the deprecation of FindBoost module as described by policy CMP0167.

A simple solution is to use:

# OLD behavior is to use the FindBoost module from cmake
# NEW behavior is to use the Boost CMake provided config files
# Boost 1.70 and above can use the new behavior
if (POLICY CMP0167)
  cmake_policy(SET CMP0167 NEW)
endif()

This however will make all builds for Boost < 1.70 fail. Currently I'm manually specifying in the tests which version of the Policy to use with -DCMAKE_POLICY_DEFAULT_CMP0167={OLD|NEW}.

The policy does specify that in future versions of cmake the FindBoost module might be removed altogether. We could consider dropping support for Boost 1.68 (Release Notes) which is pretty outdated by now (2018) and always set the policy to NEW.

Some of the macOS errors are caused by an incompatibility with Clang that was fixed in Boost 1.81: boostorg/numeric_conversion@50a1eae

@cbrl Should we then test on macOS only from 1.81 onwards?

@cbrl Should we then test on macOS only from 1.81 onwards?

Probably. That specific error I linked to happens in Clang 16+, so only starting with macOS 15. However, macOS versions <15 still have other various compile errors in earlier versions of the Boost libraries.